Radio Resource Control (RRC) transaction failures are common in commercial telecommunications networks, e.g. Long Term Evolution (LTE) networks. Such failures have a significant impact on the customer's perception of signal quality, as even if the transaction is recovered, the delay due to the recovery process will often be large enough to affect quality of service.
RRC transactions use Radio Link Control Acknowledged Mode (RLC AM) to deliver on the data layer. An RLC entity receives/delivers RLC Service Data Units (SDUs) from/to upper layers and sends/receives RLC protocol Data Units (PDUs) to/from its peer RLC entity via lower layers. Each sent PDU is assigned a Sequence Number (SN). The SN is used to allow the receiver to provide the transmitted data in the correct order, even if certain packets are received out of sequence. In the event that the receiver detects a gap in the sequence, it can send an RLC STATUS PDU to the transmitter requesting retransmission of the missing data PDU. Additionally, the transmitter may poll the receiver in order to trigger status reporting, and in response the receiver will send an RLC STATUS PDU indicating any gaps in the received sequence numbers, the sequence numbers of any partially received PDUs, and/or the next expected sequence number (which is an implicit acknowledgement of all PDUs with lower sequence numbers).
The transmitter will generally poll for updates whenever it would be unable to send an RLC data PDU following the PDU currently being transmitted, e.g. if both the transmission buffer and retransmission buffer are empty, or if the next sequence number to be transmitted would fall outside of the transmitting window. The transmitting window is defined by two variables, VT(A), which is the lowest sequence number of the sent PDUs that remains to be acknowledged, and VT(MS), which is VT(A) plus the size of the transmitting window. The SN of the next PDU to be sent is assigned to the variable VT(S), and a PDU may only be sent if VT(A)≤VT(S)<VT(MS).
Whenever a PDU is transmitted from the RLC transmitter, a copy of the PDU will be saved in the retransmission buffer. PDUs for which reception has been acknowledged by the receiver will be removed from the retransmission buffer. In the event that the transmitter receives a STATUS PDU indicating that a PDU was not received, or only partially received, the transmitter will retransmit the PDU or segment of the PDU (‘resegmentation’ as set out in 3GPP TS 36.322). The PDU or segment of PDU that is retransmitted will remain in the retransmission buffer for as long as it is not acknowledged. A counter is incremented for each retransmission attempt, and if the counter exceeds a threshold, then the transmission is reported as failed to a higher protocol layer. Such a complete failure will generally occur 0.5-2.5 s from initial transmission depending on the configuration of the RLC transmitter.
Such failures can be particularly problematic during user equipment (UE) connection reconfigurations such as those relating to handover. These particular transactions often stall due to temporary radio outages on the downlink (DL) connection to the UE. In the case of handover, the process is initiated by the UE sending a measurement report, following which the eNodeB chooses to initiate handover if the UE would receive better service on another eNodeB, or for load balancing purposes. If an RLC delivery failure is experienced for a handover command sent to the UE, the Radio Access Control (RAC) will wait for an attempt by the UE to re-establish the connection. However, there is still a serious interruption to services for the UE, which can cause ongoing sessions to fail.
The UE will remain in the source cell, and continue sending measurement reports, but the RAC controller in the source eNodeB will not react (as it considers the connection with the UE to be in the process of being handed over). This situation will continue until a handover timeout expires in the RAC controller of the eNodeB (generally around 10s from the start of handover), or the UE triggers a Radio Link Failure (RLF) due to an uplink (UL) RLC failure. It is not desirable for the RAC to order retransmission of the handover command following notification of failure by the RLC. If the later handover command is received, its data will necessarily be processed by RLC with a higher sequence number than that of the previous handover command, which would cause the RLC layer in the UE to request the data corresponding to the previous handover command to be resent before delivering the data of the later command. The RLC layer will make sure of in-sequence-delivery, thus making sure the commands arrive at the RRC layer in the order that they were sent. This would result in the UE first making a handover from the source cell to the destination cell, and then making a second handover within the destination cell (i.e. from the destination cell to the destination cell).
Any solution in which the eNodeB releases the UE after a timer, or after the UE triggers an RLF, will significantly impact service quality as the UE will have no service during the timer or until the RLF is triggered. The time required could cause sessions to time out, e.g. ending voice calls or video streams. Reducing the time between consecutive retransmissions would increase the load on the downlink in the event of a permanent radio outage, and would risk terminating the handover process in cases where the connection is degraded but not completely lost.
The RLC failures are often due to short interruptions in the downlink connection, due to brief periods where the radio signal is weakened due to obstruction or interference. Therefore, one possible solution would be to simply increase the number of retransmission attempts of an RLC PDU. However, this would also increase the load on the downlink connection, and cause a general drop in quality of service, as the retransmission attempts would each take up downlink bandwidth. Alternatively, the time between retransmissions could be increased, but this would decrease the initial redundancy in the connection, and cause very short outages to have more significant effects. Other solutions with e.g. dynamic timing of the RLC polls may be proposed, but all such solutions share the problem that they are internal to the RLC layer, and therefore unaware of details which may be known to higher layers, therefore may be sending wasteful retransmissions.